@Eekle, @kkoppul2, @beastbytes

I've made significant updates to the TSC driver that you've previously contributed to and might still have interest in. While you may not have approval rights for this repo, I'd appreciate any insights you might have.

The small additions I made the TSC driver are pretty much my greatest contribution to embassy :P So I don't really feel I can offer you much insight, unfortunately.

But thank you for working on this peripheral, and good luck!

bender run

Is anything preventing this PR from being merged? I'd be glad to help if needed!

Is anything preventing this PR from being merged? I'd be glad to help if needed!

From my point of view its ready :)
I am also ready to comply with change requests, or get help with dealing with change requests if there might be such.

I've been trying this PR and it's great. Thanks!

I do have some feedback regarding naming : it's a bit inconsistent regarding the use of a Tsc prefix. Some elements don't use it (which I like better):

tsc::Group;
tsc::pin_groups::PinGroup;
tsc::pin_groups::G1IO1Pin;

But some elements repeat a Tsc (or tsc_) prefix (which I don't like). For example:

tsc::tsc_io_pin::TscIOPin;
tsc::TscAcquisitionBankReadings;
tsc::TscAcquisitionBank;
tsc::TscAcquisitionBankStatus;

I think it'd be better to ditch all the prefixes and rely exclusively on namespacing. This would yield:

tsc::Group;
tsc::pin_groups::PinGroup;
tsc::pin_groups::G1IO1Pin;
tsc::io_pin::IOPin;
tsc::AcquisitionBankReadings;
tsc::AcquisitionBank;
tsc::AcquisitionBankStatus;

(Note that this is not an exhaustive list).

I also have a question regarding the use of MAX_GROUP_STATUS_READ_ATTEMPTS in the examples: why is it needed? In which scenario could a reading fail only for it to succeed after a short while? Shouldn't pend_for_acquisition() implement all the required delay?

@Ecco Thanks for the feedback! I've made the following changes:

1. Removed all 'Tsc' and 'tsc_' prefixes. You're right, it does cut down on the noise in the code.

2. Ditched the MAX_GROUP_STATUS_READ_ATTEMPTS check in the multipin examples. Good catch - it was leftover from an old misguided experiment and I believe such a check should not needed with async pend_for_acquisition().

I've rebased with latest main and pushed the updates as separate commits.

Hi first of all thanks for this PR, I have tried the f3 blocking example with a stm32f303k8 and confirm that it works! Now I'm trying to transfer the multipin example from stm32l4 to the f3. I noticed in the description of the example that the set_active_channels() method is mentioned here, but set_active_channels_mask() is used in the code, is there a reason for this?

Hi first of all thanks for this PR, I have tried the f3 blocking example with a stm32f303k8 and confirm that it works! Now I'm trying to transfer the multipin example from stm32l4 to the f3. I noticed in the description of the example that the set_active_channels() method is mentioned here, but set_active_channels_mask() is used in the code, is there a reason for this?

@dulouie good catch, and thanks a lot for testing! Seems this was simply a mismatch between example code and example description. Actually looking at the examples again, I realized that using set_active_channels_bank is more clear.
I have now also added a multipin example for STM32F3. However, I have created it as a 'blocking' (and not async) example since I am having trouble with STM32F3 and exti for TSC. I encountered this problem long ago #3163, but did not get time to look further into it. Its unlikely that I will be looking into that specific exti issue with STM32F3 since I most likely will be using STM32L4 for my personal projects moving forward.

I have also rebased with changes from latest main for good measure.